If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#2531 The deobfuscator doesn't deobfuscate the traps inside the SWF
Author: 
Adamillo
AdamilloDate created:
Type: bug
Visibility: Everybody
Assigned to:
Labels: AS3Deobfuscation
State: new 
> What steps will reproduce the problem?
Use the P-code deobfuscation option found in tools, remove every trap for the whole SWF,
save the changes, then reload the SWF and you'll see that it didn't manage to actually
deobfuscate the SWF
> What is the expected output? What do you see instead?
The expected output is that it should be deobfuscated
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
Stable v24.0.1
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
I'm working on porting over the packagenamespaces of a unobfuscated version of Red Ball 4
Volume 1 found on coolmathgames over to the notdoppler version with proper names. The
reason I'm doing it this way because the version coolmathgames removed some features that
were there inside the notdoppler version! If it's helpful in any way, I'm gonna upload the
SWF for both the obfuscated vanilla version of Red Ball 4 Volume 1 featured on notdoppler
and the unobfuscated vanilla version featured on coolmathgames, and I'm gonna upload the
SWF with the attempted deobfuscation.
redball4 - obfuscated.swf (9,002 KiB)redball4 unobfuscated.swf (8,983 KiB)redball4 attempted deobfuscation.swf (8,969 KiB)
Please describe more "The expected output is that it should be deobfuscated".
Remember that you cannot retrieve original identifier names this way.
P-code deobfuscation will fix the p-code problems, not problems with identifiers.
P-code problems in most cases = §§pop / §§push instructions (marked as red) found in
code,
not invalid identifiers like §if 59§ for a variable name.
If you want to "fix" invalid identifiers, then you need to run "Fix invalid identifiers"
operation,
but use it at your own risk. It will not retrieve original names - only rename them to be
valid.
If you didn't mean identifier deobfuscation,
then please tell me exact name of class which you think we did not manage to deobfuscate.
I'm not talking about identifiers. I'm talking about the P-Code deobfuscation. Here's a
demonstration of the issue
2025-09-11 18-08-36.mp4 (7,007 KiB)hmm, you're right.
I'm not really into fixing this.
You can use "Automatic deobfuscation" or "Deobfuscate code" (in nightly)
option on Settings tab instead, it does the same thing, works, and is not destructible.
There is usually not a reason to use "P-code deobfuscation" tool.
It was originally introduced as a way to convert SWFs so they can be opened in another
decompilers, but it is not really needed now. I am thinking about removing that feature
completely. It only confuses users.
So that means if I wanted to clean up the SWF with no P-Code obfuscation with no
obfuscation whatsoever, I'd have to manually do it like I did with the identifiers?
You don't need to clean up the P-code as FFDec correctly decompiles it even if it's
obfuscated.
You just need to enable "Automatic deobfuscation" or "Deobfuscate code" mode.
The current "P-code deobfuscation" tool does not actually make a total cleanup - it just
modifies code to be readable with FFDec. It also inserts some special instructions like
deobfuscate_pop, which is pop alternative, but unfortunately it saves back to file as
regular pop which makes reloading the SWF bad again.
Designing a tool which will not use deobfuscate_pop but actual remove popped instructions
would be hard and I think not worth it. I really think "P-code deobfuscation" tool is not
needed as it can be done automatically behind the scenes.
While the AS code view gets changed when deobfuscate code gets turned on, but it doesn't
do that for the P-code too. It still shows the original obfuscated code. This doesn't
happen with AVM1 code whatsoever, so both P-code and AS gets updated when deobfuscate code
option is turned on. Would be appreciated if that was fixed
I mostly edit small changes in P-Code and as mentioned, unlike AS view, it is not
deobfuscated. For the most part I manually remove the traps (simple condition that is
never met) , but in some cases methods have lots of branches, which makes it confusing and
easy to make a mistake, then I hit the Deobfuscate P-Code button (for method only) and
that saves me a lot of headache. Please, don't remove it.
Unless it can reliably auto deobfuscate it "behind the scenes". Can it be reliable?